home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_100 / 173_01 / warning < prev    next >
Text File  |  1980-01-01  |  6KB  |  150 lines
  1. < Warning >
  2.  
  3. This warning is made based upon the article, in The C Users Group Newletter 
  4. Sept/Oct, 1987, written by Victor Volkman and the letter from Michael Yokoyama.
  5.  
  6. * Victor Volkman *
  7.  
  8.     Public domain (PD) lex program CUG has several syntax-level 
  9. incompatibilities with the original Unix system specifications. First, in the 
  10. definitions section Unix lex specifies:
  11.     "Any line in this section not contained between %{ and %}, and 
  12. beginning in column 1, is assumed to define Lex substitution strings. The 
  13. format of such string is
  14.  
  15.     name     translation
  16.  
  17. and it causes the string given as a translation to be associated with the
  18. name. The name and translation must be separated by at least one blank or
  19. tab, and the name must begin with a letter." (Unix lex, Section 6)
  20. But in PD lex, the syntax of the name definition requires more delimiters
  21. than Unix lex:
  22. "A definition has the form:
  23.  
  24. expression_name = regular_expression;
  25.  
  26. where a name is composed of a lower-case letter followed by a sequence 
  27. string of letter and digits, and where an underscore is a letter." (PD
  28. lex, Section 2.4)
  29.     The additional syntax overhead and the lowercase restriction requires 
  30. modifying existing Unix lex specification files for PD lex. For example, the 
  31. Unix lex specification
  32.  
  33.     letter     [a-z][A-Z]
  34. becomes
  35.     letter = [a-z][A-Z];
  36.  
  37.     Second, another syntax disparity occures in the rules section. The 
  38. rules section is a table of regular expressions and their corresponding actions.
  39. The Unix lex specification makes no restrictions about the case sensitivity
  40. of the regular expression names. However, PD lex enforces an upper-case 
  41. restriction on regular expressions similar to its lower-case restriction in
  42. the definition section:
  43.     "Outside a string, a sequence of upper-case letters stands for 
  44. sequence of the equivalent lower-case letters, while a sequence of lower-case 
  45. letters is taken as the name of a LEX expression." (PD lex, section 2.1)
  46.     This means that an existing Unix lex specification like
  47.  
  48.     while    {return(WHILE);}
  49.  
  50. must be changed to:
  51.  
  52.     WHILE    {return(WHILE);}
  53.  
  54.     Unix lex users will immediately notice the absence of a string variable
  55. called yytext which contains the actual pattern match. The Unix lex 
  56. specifically names this:
  57.     "In more complex actions, the user will often want to know the actual
  58. text that matched some expressionn like [a-z]+. Lex leaves this text in an
  59. external character array names yytext". (Unix lex, section 4)
  60.     However, PD lex does not provide this built-in yytext variable. 
  61. Fortunately, a file called GETTOK.C provides a routine gettoken() which must be
  62. used to make yytext available. The following call will also properly set yyleng.
  63.  
  64.     yyleng = gettoken(yytext, sizeof, yytext);
  65.  
  66.     The PD lex processor does not support all of the regular expression 
  67. operators which are supported by Unix lex. These operators are simply ignored 
  68. in the PD lex documentation. When used in a lex file they do not produce errors
  69. but do not match regular expressions either. The missing operators as found in 
  70. Unix lex, section 12:
  71.  
  72.  
  73.     operator use        semantics
  74.  
  75.     .            any character but newline
  76.     ^x            an x at the beginning of a line
  77.     <y>x            an x when Lex is in start condition y
  78.     x$            an x at the end of a line
  79.     x?            an optional x
  80.     x+            1,2,3 ... instances of x
  81.     x{m,n}            m through n occurrences of x
  82.     
  83.  
  84.     Lastly, the IBM-PC adaptation is severely limited in its workspace for 
  85. creating the lex tables. This small-model implementation means tha lex is
  86. limited to rules that it can process in a 64K data segment. A large-model
  87. implementation, while somewhat slower, would allow lex to access the full 640K
  88. memory. A future release of PD lex should be considered in order to remove this
  89. restriction.
  90.  
  91.     Depending upon the severity of your compiler's error checking 
  92. mechanism, you may notice several warnings and errors for the sample lex and C
  93. files provided. For example. the Lattice C compiler insists that all externally 
  94. declared items match their declarations. This means that a procedure declared
  95. void in lex.h must also be void in the C files. Another caveat concerns the 
  96. use of variable-number argument function calls. Many C compilers will not 
  97. generate code to correct for user-functions with variable-number arguments 
  98. like they do for scanf() and printf(). Functions like lexerror() should be
  99. normalized to a fixed number of arguments (e.g. four arguments). Also, be 
  100. aware that passing structures as function arguments is implementation 
  101. dependent. Passing the address of a structure via pointer or address operator
  102. is highly recommended.
  103.     Unless you are using the DeSmet C compiler (C88) then you should use 
  104. the stdio.h file which came with your compiler. The DeSmet C stdio.h relies on
  105. the low-level implementation of file handles as an integer in MS-DOS. 
  106. Compilers such as Lattice C use structures (instead of integers) like _iobuf
  107. for higher-level I/O functions like scanf() and putc().
  108.     Perhaps the biggest danger is the cavalier assumption that integers 
  109. and pointers are equivalent. Kernighan and Ritchie thought this abuse 
  110. important enough to discourage its use by devoting a section (5.6) of "The C
  111. programming Language" to it. Experienced MS-DOS programmers will note that
  112. pointers and integers are equivalent ONLY in the small model (less than 64K
  113. cod, less than 64K data). This is invalidated in large model compilers (more
  114. than 64K code more than 64K data) where pointers are 32-bits. Working with 
  115. long 32-bit integers can help alleviate this problem.
  116.  
  117. * Michael Yokoyama *
  118.  
  119.     PD Lex differs from UNIX Lex in that while in UNIX Lex the translation
  120. may be omitted, in PD Lex the translation is required. One technique that 
  121. seems to work is to provide an entry of [\0 - \0377]; where the blank is used
  122. in UNIX Lex.
  123.  
  124.  
  125. Example.
  126.     UNIX Lex            PD Lex
  127.  
  128.     letter [a-zA-Z]            letter = [a-zA-Z];
  129.     digit [0-9]            digit = [0-9];
  130.     other                other = [\0-\0377];
  131.  
  132.  
  133.  
  134. If you find any more difference between Unix Lex and PD Lex, please feel free
  135. to write us or call us.
  136.  
  137. CUG.
  138.  
  139.  
  140.     
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.         
  148.  
  149.  
  150.